Ok, now that I try to ship this using my existing scripts it seems a little problematic to have things in master that we're not yet ready to ship. I think we should start doing PRs against 'develop' now unless we're preparing a release branch. I just updated develop to the latest state of master and pushed it so you should be able to sync it now.

So from my fork, I should now start creating new feature branches off of develop, right?

For my function breakpoints branch (off of master), can I PR that to the PSES/develop branch? Or would that cause problems?

BTW do we want to follow the same approach for vscode-powershell?

Yeah, create them off of develop. In fact, you can create feature branches in this repo if you want instead of maintaining your own repo. You should be able to git push your branches here without any trouble.

For your current work you should be able to do a PR against develop without any issues provided that develop is up to date with master at the time you do it. Once I merge my PR I'll have to merge it into develop manually. After that we can just do all PRs against develop and then only merge back into master at release time.

vscode-powershell has been a lot simpler to deal with because of the reduced volume of PRs but it might make sense to follow the same strategy there too.

I was just able to create a tag directly from the release branch. After deleting the release/0.4.3 branch the tag seems to still be there correctly. I think that creating a tag on a commit regardless of the branch keeps the history even if it isn't a part of master's timeline.

Maybe we can try doing this for a while and not introduce the added complexity of a develop branch? What do you think? I can just update my release script to be able to deal with release branches in the rare cases that they're needed.

So to create a bug fix release - say 0.4.4 - do you create a branch like rel044 and merge work into that branch and then back up to master? I know how I'd do branching with TFS but not as sure with Git.

FWIW I'm all for "less ceremony" until it's demonstrably needed. :-)

You can create a branch from a release tag pretty easily:

git checkout -b release/0.4.4 v0.4.3

Any work for that minor release can be PR'ed and merged into that branch, a release can be cut and tagged from there, then it can be rebased onto master to be merged back in to mainline development. It takes a little more work but I'm willing to put up with that so that we don't need to deal with yet another branch in our everyday work.